1. Field of the Invention
The present invention relates to a co-verification system employing programmable logic devices and other resources for verifying the behavior of an electronic circuit described by a netlist, and in particular to a method of programming such a co-verification system.
2. Description of Related Art
A typical digital integrated circuit (IC) employs register transfer logic (RTL) wherein each block of logic within the IC includes input and output registers for synchronizing state changes in its input and output signals to edges of a clock signal. Typically a designer will first generate an RTL level hardware description language (HDL) netlist employing Boolean expressions to characterize each block of logic. The designer then employs a synthesis tool to convert the high level netlist into a gate level HDL netlist describing the logic blocks as sets of cells interconnected by nets, where each cell is a standard IC component such as a transistor or a logic gate. The gate level netlist references each cell instance in the IC by referring to an entry for that cell type in a cell library, a database describing the behavior and the layout each kind of cell that can be included in an IC. After creating the gate level netlist, the designer employs a placement and routing (P&R) tool to convert the gate level netlist into an IC layout file indicating the position and layout within a semiconductor die of each cell forming the IC and describing how the nets are to be routed between cell terminals. The layout file guides fabrication of the IC.
Simulation
An IC designer usually employs various tools at each step of the design process to verify that an IC described by a netlist (or some portion thereof) will behave as expected in response to a pattern of input signals. One type of verification tool is a circuit simulator, a computer programmed to simulate the behavior of the IC by implementing a mathematical model of the IC. As illustrated in FIG. 1, to program a simulator, the designer develops a “testbench” 10 incorporating the netlist 12 describing the IC and a “vector file” 14 indicating how the IC's input signals are to change state over time. The testbench also indicates which IC signals that are to be monitored during the simulation. A compiler 16 then generates a program for a computer-based simulator 20 based on the testbench 10 and on the behavioral descriptions provided by the cell library 18 of instances of cells to be incorporated into the IC. As it executes the program, simulator 20 generates a “dump file” 22 indicating time time-varying behavior of the monitored IC signals that the designer can analyze to determine how the IC will behave.
Although a simulator can predict the behavior of an IC based on either an RTL level or gate level netlist, it can require much processing time to simulate IC behavior. To reduce processing time a designer can program a simulator to simulate only those portions of an IC design that are new or have been modified, but this approach may not provide sufficient assurance that the new and old portions of the design will properly work together.
Emulation
An emulator is another kind of verification tool a designer may use to verify the behavior of an IC described by a netlist. An emulator employs programmable logic devices (PLDs) such as, for example, field programmable gate arrays (FPGAs) to emulate the logic of the IC. For example U.S. Pat. No. 6,377,911 issued Apr. 23, 2002 to Sample et al, describes a logic emulation system employing FPGAs. Since the FPGAs employ logic gates rather than software to emulate circuits, emulation using FPGAs can often be much quicker than computer-based simulation.
As illustrated in FIG. 2 one or more compilers 24 compile the netlist 12 describing the IC and the cell library description of the cells to be included the IC into programs for the PLDs and any other programmable resources included in emulator 26. Another compiler 28 compiles the vector file 14 into a program for a pattern generator 30 for providing input signals to emulator 26. Compiler 28 also compiles a program for a data acquisition system 32, such as a logic analyzer, for monitoring various signals within emulator 26 to determine how the emulated circuit behaves in response to the input signals provided by pattern generator 30.
In-Circuit Emulation
An IC normally operates in the context of a host system such as a printed circuit board (PCB), communicating with other devices mounted on the PCB. In an in-circuit emulation (ICE) system, a circuit emulator is connected to a host system circuit in place of the IC it emulates so that the emulated IC can be tested within the intended operating environment of the IC. As illustrated in FIG. 3, an emulator 26 is connected through cables to an IC socket on a host system 34 in which the emulated IC will eventually be installed. During an emulation process, while the emulator communicates with host system 34 via input and output signals, a data acquisition system 32 acquires data representing the behavior of those signals that an IC designer can analyze to verify behavior of the emulated IC.
Emulation Hardware
FIG. 4 illustrates a typical prior art emulation system 40 including a set of circuit boards 42, each holding an array of FPGAs 44, with each FPGA programmed to emulate the logic of a large number of interconnected logic gates and storage devices such as flip-flops and registers. Each FPGA 44 has many I/O terminals and some of those I/O terminals are linked to I/O terminals of other FPGAs 44 on the same circuit board 42 so that the FPGAs can communicate with one another. Circuit boards 42 reside in slots on a motherboard 45 including a backplane providing signal paths between I/O terminals of FPGAs 44 residing on different circuit boards 42. In some systems, the signal paths between FPGAs or FPGA boards are linked via programmable routing devices such as crosspoint switches to provide more flexible signal routing between FPGAs. A conventional computer workstation 46 processes the user's netlist description of the emulated IC device under test (DUT) to produce a set of instructions for programming FPGAs 44 to emulate DUT logic. The workstation transmits those instructions to programming inputs of FPGA 44 via one or more input/output (I/O) interface cards 47 installed in a slot of the PCI bus of workstation 46.
A pattern generator 55 and a data acquisition circuit 56 may be mounted on circuit boards installed in motherboard 45 and linked through signals paths on the motherboard to I/O terminals of FPGAs 44. These circuits supply input signals to the FPGAs and monitor selected FPGA output signals during the emulation process to acquire “probe data” representing the behavior of the DUT output signals. Following the emulation process, a user may employ debugging software to analyze the data acquired by data acquisition system 56 to determine whether the DUT will behave as expected. When the emulator is employed for in-circuit emulation, a cable 52 provides signal paths between I/O terminals of FPGAs 44 and a socket of a host system 54.
Co-Verification
An IC may include large standardized components such embedded computer processors and memories, and in lieu of using programmable logic devices to emulate the behavior of such components, system 40 of FIG. 4, acting a “co-verification system” may employ a suitably programmed workstation 46 to simulate the behavior of an embedded processor and memory while the FPGAs 44 emulate various logic blocks of the IC. During the co-verification process, FPGAs and workstation 46 communicate though backplane wiring in motherboard 45. Processors and memory ICs mounted on other resource boards 48 installed in slots of motherboard 45 can be also used to simulate large component behavior.
FIG. 5 is a dataflow diagram illustrating how various parts of co-verification system 40 of FIG. 4 might implement an IC device under test (DUT) and the various test functions of a testbench using a co-verification process to simulate and emulate various modules of the DUT. The netlist included in the testbench describes the DUT as having several modules, and in this example workstation 46 simulates some of the DUT modules 60 while resource boards 42 emulate other DUT modules. In this example, software within workstation 46 also handles the test vector generation 62 and data acquisition 64 functions specified by the testbench. Backplane wiring on motherboard 45 of FIG. 4, cables and/or other interconnect systems provide signal routing 66 between workstation 46, resource boards 42, pattern generator 55 and data acquisition system 56. A “transactor” 68 implemented by software and hardware within workstation 46 provides an interface between the vector generator software 62, the data acquisition software 64, the DUT modules 60 simulated by workstation 46, and signal routing system 66. Signal routing system 66 routes output and input signals of DUT modules 61 to input and output terminals of transactor 68.
To change the state of one or more inputs to an emulated DUT module 61, simulated DUT modules 60 or vector generator 62 will send a high level “write” command to transactor 68 formatted, for example, as follows:                write location dataThe “write” command indicates one or more DUT input signals identified by the “location” field of the command are to be driven to states indicated by the “data” field of the command. Transactor 68 responds to the write command by setting the input signals at the indicated DUT module 61 inputs to the indicated states. A DUT module 60 or data acquisition system 64 sends a “read” command to transactor 68 when it needs to determine the state of one or more DUT module 61 output signals. For example, the read command may appear as follows:        read locationThe “location” field references the DUT module 60 output signals whose states are to be read.        
The location field in the read and write commands identifies DUT module 61 input and output signals by identifying particular terminals of workstation 46 at which those signals appear. Thus when compiling programs for workstation 46 implementing DUT modules 60, vector generator 62 and data acquisition system 64, it is necessary to first map each signal through which DUT modules 61 communicate to separate hardware input/output (IO) terminals of workstation 46 because it is necessary for the compiler to know which terminals will transmit and receive each DUT module 61 IO. Conversely, when programming the PLDs on resource boards 42 to emulate modules 61, it is necessary to tell the compiler for the PLDs which terminals of workstation 46 are to send and receive the IO signals of module 61 input and output signals.
An IC designer will initially create a netlist using high level Boolean expressions to describe each IC module, but as the design process progresses the designer will employ synthesis and other tools to convert the high level netlist description of IC modules to gate level and lower level descriptions. In the co-verification system of FIG. 5, workstation 46 is best suited for implementing DUT modules 60 at a high level of abstraction while resource boards 42 are often better suited for implementing DUT modules 61 at a lower level of abstraction. As the IC design progresses, the designer may want to use the co-verification system several times, changing the manner in which DUT modules are allocated between workstation 46 and resource boards 42. For example a module may initially be simulated by workstation 46 while its design is at a high level of abstraction, and then later emulated by resource boards 42 after the designer has synthesized its gate level design.
One drawback to the co-emulation system of FIG. 4 is that it is necessary to use separate compilers to compile programs for each system component, since workstation 46, pattern generator 55, data acquisition system 56 and devices on resource boards 48 include different memories and map signals to different memory space addresses. The designer must carefully coordinate the compilers for the workstation software and the compilers for the PLDs so that the various parts of the co-verification system will properly communicate with one another during the co-verification process. When the designer wishes to reallocate a DUT module from workstation 46 to resource boards 42, it is necessary to not only compile a new resource program for that module but to also recompile programs for all other modules as well, because the IO terminal locations of the module that migrated from workstation to resources boards have changed. The compilers must change the write and read commands generated by vector generator 62, data acquisition block 64 and the remaining simulated DUT modules 60 to account for the new terminal locations of the migrated module. Since the time required to compile the PLD programs and workstation software can be considerable, the need to recompile this programming as the IC design progresses in order to verify the IC design at each stage of the design process significantly adds to the total time needed to design an IC.